Nearly everyone with a relatively fast Internet connection has experienced streaming audio and video, whether by listening to a favorite music station, watching a news report, or accessing similar streaming content. However, streaming media is not just for entertainment. With the help of multicast technology, a company can broadcast corporate messages, training classes, or meetings directly to employees' desktops.
Examples of many-to-many applications include conferencing (video, audio, and whiteboard sharing), collaborative document sharing, interactive distance learning, and virtual reality. Other specific uses for multicast can include the real-time distribution of weather, stocks, telemetry, and remote sensing data. In addition, file distribution can be multicast such as software updates, database mirrors, and web caching. Multicast technology can even be used for cryptographic key or seed value distribution, network management, system configuration, and similar operations.
Streaming content is generally distributed to the desktop in one of two ways: point-to-point unicast or multicast. Unicast streaming is the method employed by World Wide Web and FTP servers, where data is sent as a separate stream from the source to each user who requests it. This method works in situations where each user wants different content and not many people want the same content at the same time.
With unicast streaming, the server capacity and size of a sender's network pipe determine the number of receivers that the sender can accommodate. Unicast also uses considerable bandwidth on receiving networks that have multiple listeners. From a programming standpoint, it is not easy to send duplicated data to many individual destinations simultaneously. A simple round-robin algorithm is insufficient because of the latency in processing a long list of recipients. With real-time data such as video and audio, many datagrams must be sent back-to-back to avoid the jitter (interpacket delays) that can disrupt the media.
Delivering the same streaming content to thousands of users via unicast is impractical because the necessary bandwidth between the originating server and the destination routers can be cost-prohibitive. Since many receivers of broadcast information get the same datastreams, these limitations and adverse effects are unnecessary. Much of this overhead can be avoided by using multicast, rather than unicast, for streaming media.
Multicast allows a content provider to send a single data stream to a single address, and then the downstream network routers subsequently distribute the data stream to as many receivers as desired. Instead of broadcasting thousands of streams, the server sends out only one stream that is propagated among multiple users who want the content. Multicast requires no additional bandwidth on the part of the sender to add new receivers, because the network routers handle the multicast distribution that is derived from the single data stream.
Using multicast streaming means the bandwidth is decreased not only at the server but also across most of the network path. This is because the bandwidth that is transmitted across the network to the multicast router is just a single stream. The network segments that consume large bandwidth quantities are located between the multicast routers and the destination desktop receivers. Of course, there may be many desktop receivers on the same network which are all requesting the same stream.
Multicast relies on the multicast backbone, which is not a separate Internet backbone. The multicast backbone is an address space laid out on the existing Internet and intranet backbones. The multicast address space occupies the Class D address range or addresses between 224.0.0.0 and 239.255.255.255. Several addresses within the range are reserved. For example, 224.0.0.1 is reserved for all hosts connected directly to the local network and 224.0.0.2 is designated for routers on a local area network (LAN).
Multicast sessions are assigned a multicast group ID, which is essentially an IP address within the Class D range. A client may join as many multicast groups as desired and can leave the multicast groups at any time. The host's physical location is irrelevant, as is the number of members in a group. IP packets sent out by the hosts look like all other IP packets with the exception that the destination address is the group IP. As mentioned, the multicast routers then have the responsibility to distribute the multicast packets to all members of the group that are downstream. In other words, the multicast router will take the individual stream and duplicate the stream into a single stream for each subscriber.
A new multicast stream is first assigned an address within the Class D range. Any client that wishes to receive the stream places that stream's Class D IP address on whichever interface it uses for IP. Because all the clients or recipients of the stream have the same Class D address, the multicast is sent to one address and thus to many recipients.
Multicast routers depend on a group membership protocol, such as IGMP (Internet Group Management Protocol), to learn about the clients connected to the subnets. When a client wishes to join a group, it sends an IGMP message to the multicast router, indicating the session(s) the client wishes to receive. The multicast router then begins broadcasting the sessions requested to the member's subnet (i.e. client) and the member adds the group ID address to its interface to begin reception. Scalability increases as more members join because there is a greater chance of locating a multicast router on a nearby upstream network.
Multicast is useless unless the streams actually make it to their intended audience and that hinges on the routing. Multicast can use at least two spanning-tree technologies to get streaming media to its destinations: dense mode or sparse mode. Dense mode floods the network tree with a broadcast so that every branch receives the signal. Branches that do not have clients requesting the signal are then pruned from the broadcast on the fly. Sparse mode works in the opposite fashion. Only those branches with clients requesting the broadcast actually receive the stream. The request from the client goes up the network tree until a multicast connection is made between the client and server. Multicast broadcasts are typically announced like anything else, through e-mail or on a Web site.
Unfortunately, IP multicasting is not perfect. For multicasting to work, every router in a network path may need to be enabled to forward the multicast packets to clients or members. This poses significant problems on older corporate networks which have routers that do not support multicast. Moreover, requiring routers to be configured to receive multicasts can create major headaches for broadcasts across the public Internet. Not every ISP, extranet partner, or dial-up remote access server has multicast-enabled networks. Even when routers are multicast capable, not all Internet Service Providers (ISPs), corporations, businesses, or network system managers enable the multicast routing. Then, even if the routers are configured properly, the routers may support different versions of multicast.
A similar problem exists with firewalls. When a network's outside traffic is routed through a secure firewall, the multicast packets are not forwarded through the firewall. In addition, a firewall does not duplicate multicast packets when it receives them. Clients who reside behind a firewall will not be able to receive multicasts. Ethernet switches are another consideration. New switches support multicast but some older models change multicast into broadcasts, which can adversely affect the network performance.
In the past, some companies have setup RTP (Real-Time Transport Protocol) level relays called translators in order to send multicast streams past firewalls. In order to use such a system, two translators are installed and one translator is located on either side of the firewall or other protective network mechanism. The outside translator funnels all the multicast packets received through a secure connection to the translator inside the firewall. The translator inside the firewall sends them again as multicast packets to a multicast group that was previously restricted by the firewall.
Since the translator receives multiple multicast streams and then resends multiple multicast streams, the translator carries a significant load when a large number of clients behind the firewall join the multicast group. Another serious drawback of translators is that a translator is a separate computer that must be setup by the network administrators or IT staff. This means that all sites with a protected network or all sites with a firewall would have to install the translator. This may be prohibitively expensive because a dedicated translator includes expensive hardware and there is also a cost for a technician to install the hardware and software. Accordingly, cost and inconvenience may prevent widespread deployment of these translator boxes. Moreover, the use of a translator may not overcome the router problems that exist across the entire Internet.